1. Field of Invention
The invention relates to the handling and storing of system configuration attributes. In particular, this invention is directed to enabling dynamic configuration through the storage and modification of configuration information as attributes of a server object in a client-server system.
2. Description of Related Art
Typically, system configuration is a static process, whereby the configuration is changed and the system must be restarted. In some systems, registry values are often used to store system configuration information. When one of these values changes, the network (or system) process must be shut down and restarted for the changes to take effect.
Similarly, as shown in FIG. 1, on UNIX, for example, configuration files 120 (typically found in /etc/*.conf) are often used to store configuration information for the network 110 and various system elements (or infrastructure facilities) 130,140,150 in the system 100. When one of these system elements 130,140,150 changes its configuration, the corresponding configuration file 120 is edited and the system 100 must have processes restarted for the changes to take effect.
This static nature of system configurations is because configuration information is only accessed at system startup. Configuration files 120 and registry entries are not suitable for dynamic configuration capabilities, because it is difficult to know when a change has occurred. Typically, information would need to be polled (reread) every single time the information is needed, if true dynamic configuration were to be implemented. However, because of the frequency this information is required, it is typically prohibitive to do this type of polling.
In an object-based client-server system, the client can set configuration attributes on the server object to store and modify configuration information. However, lowlevel infrastructure facilities (e.g., naming, security, file access, etc.) often require configuration information and the object code is typically built on top of this infrastructure. To avoid circular dependencies and maintain proper layering, the infrastructure facilities cannot use or be dependent upon the object code. Hence, the infrastructure code cannot access the server object to obtain the necessary configuration attributes.